Description

@swift-nav/devinfra

If an SBP message has a variable length array of some type, when decoding a input wire encoded buffer which has been truncated the decoder will not produce an error when it should.

Imagine a message containing some amount of overhead, then a variable length array of some type.

+---------------------------------------+
| header | elem0 | elem1 | .... | elemN |
+---------------------------------------+

In this message the array is not fixed length, rather the number of elements is variable and is calculated from the size of the input buffer:

num_elems = (sizeof(input_buffer) - sizeof(header)) / sizeof(elem)

Decoding of each element is then performed in a loop:

for (int i = 0; i < num_elems; i++) {
  result = decode_elem(buffer, &output[i]);
}

If the size of the header is 3 bytes and the size of each element is 4 bytes an example representation on the wire could be:
offset

      0   1   2   3   4   5   6   7   8   9   A   
      +-----------+---------------+---------------+
      | header    | elem0         | elem1         |
      +-----------+---------------+---------------+

And so long as this is what’s fed in to the decoder then num_elems will be correctly calculated as 2 and all input data will be consumed.

But if the input buffer is somehow truncated:

offset
      0   1   2   3   4   5   6   7   8   
      +-----------+---------------+-------|
      | header    | elem0         | elem1 |
      +-----------+---------------+-------|
                                          ^
                                          abnormally truncated at this point

then due to integer rounding num_elems will be calculated as 1. Only the first element of the array will be decoded (and it will succeed), but the truncated data at the end of the input buffer will not be considered at all.

The correct behaviour in this situation should be for the decoder to notice that the input buffer does not contain an integer number of elements in the variable length array and return an error

API compatibility

Does this change introduce a API compatibility risk?

No

API compatibility plan

If the above is "Yes", please detail the compatibility (or migration) plan:

N/A

JIRA Reference

https://swift-nav.atlassian.net/browse/AP-948